feat(ember): v2 #19229

aklkv · 2026-02-08T07:04:23Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
Link an issue if there is one related to your pull request. If no issue is linked, one will be auto-generated and linked.

Summary

Migrates @sentry/ember from the legacy v1 addon format to the Ember v2 addon format. This modernizes the package to work with both classic Ember builds and Embroider-optimized builds, and removes the runtime dependency on @embroider/macros.

Changes

Build system: Replaced ember-cli build pipeline with rollup (transpilation → dist/) + tsc (declarations → declarations/)
Addon entry: Added addon-main.cjs using @embroider/addon-shim as the addon entry point
Package.json: Set ember-addon.version: 2, updated exports map, added ember-addon.app-js mapping
Config format: Replaced @embroider/macros getOwnConfig() with explicit Sentry.init() calls and a new setupPerformance() export

API changes:

init() is now called directly in app.ts or an initializer (no more ENV['@sentry/ember'] config)
setupPerformance() must be called from an instance-initializer to opt into performance instrumentation
Initial load instrumentation requires manual <script> tags in index.html
Added UPGRADE.md with detailed migration guide

Test & CI updates:

All 21 unit tests passing (acceptance tests for errors, performance, and replay)
Updated e2e test apps (ember-classic, ember-embroider) to use v2 patterns:
- Added instance-initializers for performance setup
- Migrated config from ENV['@sentry/ember'] to Sentry.init() in app.ts
- Added initial load <script> tags to index.html
Updated .github/workflows/build.yml CACHED_BUILD_PATHS from packages/ember/*.d.ts to packages/ember/dist + packages/ember/declarations

TypeScript fixes:

Added "types": ["ember-source/types"] to tsconfig.publish.json for Ember module resolution during declaration generation
Fixed transition type imports (removed non-existent @ember/routing/-private/transition)
Simplified instrumentFunction generic to avoid tuple mismatch errors

Breaking Changes

ENV['@sentry/ember'] config in config/environment.js is no longer supported — use Sentry.init() directly
Performance instrumentation is no longer automatic — call setupPerformance() from an instance-initializer
Initial load tracking requires manual <script> tags in app/index.html

Closes #15835

nicohrubec

Hey, thanks for contributing. A few notes:

This PR is way too large. Please split it up into smaller pieces so we can review it properly.
Is there a way to get this done without introducing breaking changes? If no, then we need to wait with this until our next major.

aklkv · 2026-02-09T11:24:12Z

Hey, thanks for contributing. A few notes:

This PR is way too large. Please split it up into smaller pieces so we can review it properly.

Is there a way to get this done without introducing breaking changes? If no, then we need to wait with this until our next major.

Hi @nicohrubec, thanks for the feedback!

I understand the concern about PR size. Unfortunately, the v1 → v2 addon migration is an atomic change — you can't incrementally migrate between formats. The build pipeline, entry point structure, and package.json layout must change together for the addon to function.

That said, the core SDK functionality is unchanged — the same instrumentation, error handling, and performance tracking code. The changes fall into two categories:

Consumer-facing setup — how users configure the SDK (direct Sentry.init() calls instead of ENV['@sentry/ember'])
Build/packaging scaffolding — the surrounding v2 addon infrastructure (Rollup config, addon-main.cjs, exports map, etc.)

The actual instrumentation logic in src/ is largely untouched. So while the diff is large, most of it is build tooling and test app updates to match the new setup pattern — not changes to Sentry functionality itself.

I'm happy to:

Add a review guide in the PR description highlighting which files contain meaningful changes vs. scaffolding
Split into multiple logical commits (build system, config API, test updates) to make review easier

Regarding breaking changes — the v2 format requires explicit Sentry.init() calls, so this would need to target the next major release.

Let me know how you'd like to proceed!

packages/ember/src/index.ts

johanrd · 2026-02-09T12:47:36Z

@aklkv thanks a lot for doing this!🙏

FWIW: While waiting for this, I realized I didn't use the performance part of the addon, and was able to just use the @sentry/browser package without the need of any ember specific addon at all.

That also means that the 'breaking change' mentioned in the PR is a very welcome change to reduce the scope of what is delegated to the 'ember' part of the addon. Most is now just handled by the core apis, which it how it should be👍

(the link to Ember v2 addon format is broken in the pr description, btw)

NullVoxPopuli

This is a good PR.

I understand the maintainer's perspective of wanting it split up tho.

The only way to do so would be rearranging the monorepo a bit to make a separate test app package.

This would mean the goal of that PR is to just delete the dummy app from the existing v1 addon.

That will still be a large pr, and i don't really see a way to get better than 2 large prs for this needed work.

Maintainers,
You mentioned breaking change timing - i suspect that is because all packages in this repo are released at once?

May i introduce you to https://github.com/release-plan/release-plan ?
It allows each package to be published independently with correct semver inference based on changes in git (and labels assessing impact on a pr) it helps a lot!

NullVoxPopuli · 2026-02-09T13:02:41Z

dev-packages/e2e-tests/test-applications/ember-classic/app/index.html

    <meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">

+    <script>if(window.performance&&window.performance.mark){window.performance.mark('@sentry/ember:initial-load-start');}</script>


What are these additions for? Are they needed?

NullVoxPopuli · 2026-02-09T13:04:19Z

.../e2e-tests/test-applications/ember-embroider/app/instance-initializers/sentry-performance.ts

Since this is an app file, did the readme get updated to reflect the situation that wants this added?

Is it required?

NullVoxPopuli · 2026-02-09T13:05:54Z

packages/ember/addon/runloop.d.ts

Good riddance

NullVoxPopuli · 2026-02-09T13:06:46Z

packages/ember/demo-app/routes/with-loading/index.ts

+  }
+}
+
+export default instrumentRoutePerformance(WithLoadingIndexRoute);


Nice way to do this!

packages/ember/src/index.ts

NullVoxPopuli · 2026-02-09T13:15:01Z

packages/ember/UPGRADE.md

Ah! My questions were answered here in this doc! Tyty!

packages/ember/package.json

cursor

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

cursor · 2026-02-09T23:21:54Z

packages/ember/src/performance.ts

+ * };
+ * ```
+ */
+export async function setupPerformance(


Unnecessary async masks errors as unhandled rejections

Medium Severity

setupPerformance is declared async but contains no await statements. The old instrumentForPerformance needed async because it had await import('@sentry/browser'), but the new code replaced that with static imports. Since all documentation and examples show calling setupPerformance without await (the instance-initializer returns void), any synchronous error thrown inside (e.g., from appInstance.lookup) becomes an unhandled promise rejection instead of propagating to Ember's boot error handling. This could silently swallow performance setup failures, making them very hard to debug.

Additional Locations (1)

dev-packages/e2e-tests/test-applications/ember-classic/app/instance-initializers/sentry-performance.ts#L3-L8

cursor · 2026-02-09T23:21:54Z

packages/ember/tests/helpers/utils.ts

+      true,
+      'runloop spans not captured (expected in strict resolver test environment)',
+    );
+  }


Runloop span test assertion unconditionally passes

Medium Severity

The runloop span assertion in assertSentryTransactions now unconditionally passes — if runloop spans exist, it asserts true (trivially true from the condition), and if they don't, it asserts assert.true(true, ...). This means regressions in runloop instrumentation can never be detected by the test suite. The old code had a real assertion that could fail. Per the review rules for feat PRs, tests need to actually test the newly added behavior.

aklkv marked this pull request as ready for review February 8, 2026 09:40

aklkv force-pushed the feat/ember-v2-format branch 3 times, most recently from 53dd617 to 822ed0a Compare February 8, 2026 11:01

nicohrubec requested changes Feb 9, 2026

View reviewed changes

aklkv force-pushed the feat/ember-v2-format branch from 822ed0a to 4874c99 Compare February 9, 2026 12:25

cursor bot reviewed Feb 9, 2026

View reviewed changes

packages/ember/src/index.ts Outdated Show resolved Hide resolved

NullVoxPopuli reviewed Feb 9, 2026

View reviewed changes

aklkv force-pushed the feat/ember-v2-format branch from 4874c99 to 34b116c Compare February 9, 2026 22:18

cursor bot reviewed Feb 9, 2026

View reviewed changes

packages/ember/package.json Outdated Show resolved Hide resolved

feat(ember): Migrate @sentry/ember to v2 addon format

3f38914

aklkv force-pushed the feat/ember-v2-format branch from 34b116c to 3f38914 Compare February 9, 2026 22:56

cursor bot reviewed Feb 9, 2026

View reviewed changes

Uh oh!

feat(ember): v2 #19229

Are you sure you want to change the base?

feat(ember): v2 #19229

Uh oh!

Conversation

aklkv commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Breaking Changes

Uh oh!

nicohrubec left a comment

Choose a reason for hiding this comment

Uh oh!

aklkv commented Feb 9, 2026

Uh oh!

Uh oh!

johanrd commented Feb 9, 2026

Uh oh!

NullVoxPopuli left a comment

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor bot Feb 9, 2026

Choose a reason for hiding this comment

Unnecessary async masks errors as unhandled rejections

Uh oh!

cursor bot Feb 9, 2026

Choose a reason for hiding this comment

Runloop span test assertion unconditionally passes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aklkv commented Feb 8, 2026 •

edited

Loading